home *** CD-ROM | disk | FTP | other *** search
/ Mastering Microsoft Visual Basic 5 / Mastering Microsoft Visual Basic 5.ISO / tools / pspy / readme.txt < prev    next >
Text File  |  1996-11-25  |  6KB  |  147 lines
  1. This document contains the installation instructions for
  2. the Process Viewer - PSpy.EXE.
  3.  
  4. Table of Contents:
  5.   I. Installation for users of Windows NT 3.51/4
  6.  II. Installation for users of Windows 95
  7. III. Running PSpy
  8.  IV. What PSPY is
  9.   V. What PSPY is Not
  10.  VI. Working Sets
  11.  
  12.  
  13. I. Installation for users of Windows NT 3.51/4:
  14. ---------------------------------------------
  15. 1. PSpy requires that Visual Basic is installed.
  16. 2. PSpy will now run from the CD.
  17.  
  18. 3. If you want to install PSpy to your machine, copy the 
  19. following files to your \System32 directory:
  20.     PERFINFO.DLL
  21.     WORKSET.DLL
  22. 4. Copy PSPY.EXE to your hard drive, and create a Program
  23. Manager icon for it.
  24.  
  25. II. Installation for users of Windows 95:
  26. -----------------------------------------
  27. 1. PSpy requires that Visual Basic is installed.
  28. 2. Copy the following file to your \System directory:
  29.     MEMMON.VXD
  30. 3. Copy the following file to the \System\VMM32 directory:
  31.     VMM.VXD
  32. 4. Add the following line to the [386Enh] section of your
  33. SYSTEM.INI file:
  34.     Device=memmon.vxd
  35. 5. Restart Windows 95.
  36. 6. PSpy will now run from the CD.
  37.  
  38. 7. If you want to install PSpy to your machine, copy the 
  39. following files to your \System32 directory:
  40.     PERFINFO.DLL
  41.     WORKSET.DLL
  42. 8. Copy PSPY.EXE to your hard drive, and create a Program
  43. Manager icon for it.
  44.  
  45. III. Running PSpy:
  46. ------------------
  47. 1. To spy on a process, choose the 'Examine' option from
  48. the Process menu.
  49. 2. Click and drag the magnifying glass on the Process you
  50. wish to view information.
  51. 3. Click OK.
  52. 4. Click on a file name on the left half of the window to show
  53. details for that file.
  54. 5. Click the "Flush" button to flush the active working set
  55. for the program you are spying on (see below).
  56. 6.  Click the "Refresh" button to refresh the working set
  57. display for the program.
  58. 7. Right clicking on either pane will bring up a context
  59. menu.  From here you can change the view and copy the
  60. display to the clipboard.
  61.  
  62. IV. What PSPY is:
  63. -----------------
  64. 1. A tool to help you locate where DLLs in memory are
  65. loaded from - much like WPS.EXE in Windows 3.1.
  66. 2. A tool to identify the versions of all DLL's that
  67. your program is using.
  68. 3. A tool to provide information on the Working Set of a 
  69. process.  See below for a description of what the Working
  70. Set for a process is.
  71.  
  72. V. What PSPY is Not:
  73. --------------------
  74. 1. PSpy is not supported by PSS, though they may have you
  75. use it to help debug a problem.
  76. 2. PSpy does not trap window messages like the Spy and 
  77. Spy++ utilities shipped in Microsoft Visual C++.
  78.  
  79. VI. Working Sets:
  80. -----------------
  81. 32 bit operating systems like Windows 95 and Windows NT
  82. support memory paging.  This means that blocks of memory
  83. that haven't been used for a while can be "paged" to a
  84. temporary file on disk, which frees up memory for other
  85. programs to use.  This mechanism allows you to run more
  86. programs than you would otherwise have memory for, and
  87. makes the operating system run smoother because it doesn't
  88. need to keep so much information in physical RAM.  This
  89. memory paging happens automatically; programs are oblivious
  90. to any paging activity.
  91.  
  92. The "Working Set" of a program is the amount of 
  93. physical RAM that the operating system is currently giving
  94. your program.  As a simple example, let's say you have
  95. a program that creates a byte array that contains 5 million
  96. elements but you only access the first ten.  If other programs
  97. need more memory, the operating system will page out all but
  98. the ten elements that you are using.  Your program doesn't
  99. know the difference and doesn't pay any speed penalty.  If,
  100. however, you later try to access element 1 million, there 
  101. will be a slight delay while the operating system fetches
  102. the memory block that contains element 1 million from disk.
  103.  
  104. A programs data is not the only component of the working
  105. set.  The actual program code is another component.  PSpy
  106. can break out the program code from the data and show which
  107. modules are using how much memory.  It can also "Flush" the 
  108. working set.  This is a special command to the operating 
  109. system that says, "make this program take NO physical RAM".
  110. As long as the program is idle, it won't take any memory.
  111. As soon as the program needs to execute code, however, the
  112. OS will page memory back in.  Flushing is a good way to find
  113. out how much memory a particular operation takes.  For example, 
  114. to find out how much memory is taken by loading a file in 
  115. an application, you would perform the following steps in PSpy:
  116.  
  117.     1.  Start PSpy and the application you want to check.
  118.         Begin spying on the app.
  119.  
  120.     2.  Click the flush button of PSpy to flush the app's
  121.         working set.
  122.  
  123.     3.  Open a file with the application.
  124.  
  125.     4.  Click the refresh button on PSpy.  This will refresh
  126.         the working set numbers for the application.
  127.  
  128. The working set numbers that are now displayed on PSpy reflect
  129. the amount of RAM required by your program to load the file.
  130.  
  131. Advanced topic:  Working Set on Windows 95 vs Windows NT
  132.  
  133. Windows 95 treats shared DLL's differently than Windows NT. Under
  134. Windows NT, the working set for a shared DLL accurately reflects
  135. the working set of the DLL for the process being monitored.  Windows
  136. 95, however, uses a shared address space for shared DLL's.  Working
  137. set numbers for shared DLL's under Windows 95 reflect the combined
  138. working set for all processes that use the DLL.  This causes working
  139. set numbers under Windows 95 to appear higher than on Windows NT.  
  140. For example, a minimal application will show a subtantial working
  141. set contribution from kernel32 because this DLL is also in use by 
  142. the system.
  143.  
  144. If you are curious about the working set or how paging works, see
  145. "Examples of Memory Activity and Paging" in the Windows NT Resource
  146. Kit under the section, "Optimizing Windows NT".
  147.